x86/altp2m: help gcc13 to avoid it emitting a warning
authorJan Beulich <jbeulich@suse.com>
Tue, 21 Mar 2023 12:45:47 +0000 (13:45 +0100)
committerJan Beulich <jbeulich@suse.com>
Tue, 21 Mar 2023 12:45:47 +0000 (13:45 +0100)
commitd84612ecab00ab31c09a7c5a5892906edbacaf5b
tree9fdf63a5e052752938649a7f980469c62b34c170
parentb5409f4e4d0722e8669123d59f15f784903d153f
x86/altp2m: help gcc13 to avoid it emitting a warning

Switches of altp2m-s always expect a valid altp2m to be in place (and
indeed altp2m_vcpu_initialise() sets the active one to be at index 0).
The compiler, however, cannot know that, and hence it cannot eliminate
p2m_get_altp2m()'s case of returnin (literal) NULL. If then the compiler
decides to special case that code path in the caller, the dereference in
instances of

    atomic_dec(&p2m_get_altp2m(v)->active_vcpus);

can, to the code generator, appear to be NULL dereferences, leading to

In function 'atomic_dec',
    inlined from '...' at ...:
./arch/x86/include/asm/atomic.h:182:5: error: array subscript 0 is outside array bounds of 'int[0]' [-Werror=array-bounds=]

Aid the compiler by adding a BUG_ON() checking the return value of the
problematic p2m_get_altp2m(). Since with the use of the local variable
the 2nd p2m_get_altp2m() each will look questionable at the first glance
(Why is the local variable not used here?), open-code the only relevant
piece of p2m_get_altp2m() there.

To avoid repeatedly doing these transformations, and also to limit how
"bad" the open-coding really is, convert the entire operation to an
inline helper, used by all three instances (and accepting the redundant
BUG_ON(idx >= MAX_ALTP2M) in two of the three cases).

Reported-by: Charles Arnold <carnold@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
master commit: be62b1fc2aa7375d553603fca07299da765a89fe
master date: 2023-03-13 15:16:21 +0100
xen/arch/x86/hvm/vmx/vmx.c
xen/arch/x86/include/asm/p2m.h
xen/arch/x86/mm/p2m.c